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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Although network nodes in the IMS Core Network should have a very high availability, some maintenance downtime 
and occasional failures are unavoidable. Communication links although designed with robust protocols between the 
network elements are also subject to failures. This document specifies a set of standardized procedures for automatic 
restoration after loss or corruption of data reducing the impact of these problems in order to improve service to the 
users. The scenarios covered here for the IMS Domain are similar to those covered in 3GPP TS 23.007 [2] for the CS 
and PS Domains. 
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Scope 



The present document specifies the procedures required in 3GPP IMS to handle a S-CSCF service interruption scenario 
with minimum impact to the service to the end user. 

NOTE: IMS Restoration Procedures covering service interruption of other network elements are not defined in this 
version of the specification. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.007: "Restoration procedures". 

[3] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and 

message contents". 

[4] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification". 

[5] 3GPP TS 29.213: "Policy and charging control signalling flows and Quality of Service (QoS) 

parameter mapping". 

[6] 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points". 

[7] 3GPP TS 29.214: "PoHcy and Charging Control over Rx reference point". 

[8] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp interface". 

[9] 3GPP TS 29.06 1 : "Interworking between the Public Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[10] 3GPP TS 29.274: "3GPP Evolved Packet System. Evolved GPRS Tunnelling Protocol for EPS 

(GTPv2)". 

[I I] IETF RFC 3361: "Dynamic Host Conflguration Protocol (DHCP-for-IPv4) Option for Session 
Initiation Protocol (SIP) Servers". 

[12] IETF RFC 1034: "Session Initiation Protocol (SIP): Locating SIP Servers". 

[13] IETF RFC 3319: "Dynamic Host Conflguration Protocol (DHCPv6) Options for Session Initiation 

Protocol (SIP) Servers". 

[14] draft- ietf-sipcore-keep-01 (Dec 2009): "Indication of support for keep-alive". 

[15] 3GPP TS 29.275: "Proxy Mobile IPv6 (PMIPv6) based MobiUty and Tunnelling protocols; Stage 

3". 

[16] IETF draft-krishnan-netext-update-notifications-00: "Update Notifications for Proxy Mobile 

IPv6". 
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Editor's note: The above document cannot be formally referenced until it is published as an RFC. 
[17] 3GPP TS 23.401: "GPRS Enhancements for E-UTRAN Access". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

Service Interruption: A period of time in which one or more network elements do not respond to requests and do not 
send any requests to the rest of the system. 

S-CSCF Restoration Information: Information required for the S-CSCF to handle traffic for a registered user. This 
information is stored in HSS and if lost, retrieved by the S-CSCF. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

LIR Location Information Request 

LIA Location Information Answer 

SAR Server Assignment Request 

SAA Server Assignment Answer 

UAR User Authorization Request 

UAA User Authorization Answer 

4 Restoration of Data in the S-CSCF 
4.1 General 

The following clauses describe the IMS Restoration Procedures for the S-CSCF service interruption in each of the 
scenarios where they apply. 



4.2 Registration Procedure 



4.2.1 Introduction 

The following clauses specify the behaviour of HSS and S-CSCF if they support the IMS restoration feature. 

4.2.2 S-CSCF Restoration after Failure 

If the UE initiates a SIP REGISTER and the S-CSCF returned by the HSS during user registration status query 
procedure fails, the I-CSCF is unable to contact the S-CSCF. In this case, regardless of this registration is an initial 
registration, a re-registration or a de-registration, the I-CSCF shall send UAR with Authorization Type set to 
REGISTRATION_AND_CAP ABILITIES to the HSS to explicidy request S-CSCF capabilities. After re-assignment of 
another S-CSCF according to the S-CSCF capabilities, the I-CSCF shall forward the REGISTER to the new S-CSCF. 
For registrations and re-registrations, S-CSCF shall proceed with the registration procedure as for initial registration, 
except for the clauses specified in 4.2.3. 

For de-registrations, S-CSCF shall proceed as for user-initiated de-registration. 
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4.2.3 S-CSCF Restoration during Registration Process 

During the registration procedure, the HSS shall send all the registered Private User Identities sharing the same Public 
User Identity which is being registered in the SAA, in addition to the basic user data to the S-CSCF. Then the S-CSCF 
compares the registered Private User Identities received from the HSS with the ones it stores. If there are any registered 
Private User Identities the S-CSCF does not have their registration data, the S-CSCF shall send SAR with Server 
Assignment Type set to NO_ASSIGNMENT to the HSS to retrieve the S-CSCF restoration information for the 
registered Public User Identity. If there are S-CSCF restoration information related to the Public User Identity stored in 
the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA to the S- 
CSCF. The result code shall be set to DIAMETER_SUCCESS. 

If there are more than one group of S-CSCF restoration information related to the Public User Identity stored in the 
HSS, which may happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include 
all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information corresponds to one 
Private User Identity. 

If the S-CSCF receives an initial registration request for a Public User Identity that does not match any Public User 
Identity currently registered with the same Private User Identity as in the request at this S-CSCF, the S-CSCF shall 
check whether there is a reg-id parameter in the Contact header in the SIP REGISTER message and whether there is an 
"sos" SIP URI parameter in the SIP REGISTER message. Only when a reg-id parameter exists and an "sos" SIP URI 
parameter does not exist, the S-CSCF shall indicate to the HSS that the registration is related to a multiple registration. 

If the HSS receives an SAR request with multiple registration indication, and the Public User Identity is stored as 
registered in the HSS, and there is restoration information related to the Private User Identity, the HSS shall not 
overwrite stored restoration information, instead, it shall send the stored S-CSCF restoration information together with 
the user profile in the SAA. The result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S- 
CSCF shall send a new SAR with Server-Assignment-Type set to RE_REGISTRATION and the User Data Already 
Available parameter set to USER_DATA_ALREADY_AVAILABLE to update the restoration information in the HSS 
in accordance to the current registration event. 

If the S-CSCF receives a user-initiated deregistration request for a Public User Identity that does not match any Public 
User Identity currently registered with the same Private User Identity as in the request at this S-CSCF, the S-CSCF shall 
check whether there is a reg-id parameter in the Contact header in the received SIP REGISTER message, 

if a reg-id parameter exists, the S-CSCF shall: 

• 1 . Send SAR with Server- Asignment-Type set to NO_ASSIGNMENT to retrieve the S-CSCF 
restoration information associated with the Public User Identity. The Result-Code shall be set to 
DIAMETER SUCCESS. 

• 2. Compare the contact address(es) received in SAA with the contact address(es) in REGISTER 
request: 

If they are not the same, the S-CSCF shall send SAR with Server- Asignment-Type set to 
RE_REGISTRATION to update the S-CSCF restoration information in HSS with the Contact 
address(es) still associated with the Public User Identity after the deregistration event. 

Otherwise, the S-CSCF shall send SAR with Server-Asignment-Type set to USER_DEREGISTRATION. 

4.3 UE Terminating Procedure 

4.3.1 Introduction 

The following clauses specify the behaviour of HSS, I-CSCF and S-CSCF if they support the IMS Restoration feature. 

4.3.2 S-CSCF Restoration after Restart 

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to 
the fact that it may have lost profile updates from the HSS in the service interruption period. If such a S-CSCF receives 
a terminating service request from the I-CSCF, it sends an SAR to the HSS for unregistered service data. In this case, 
HSS and S-CSCF proceed as indicated in 3GPP TS 29.228 [3], except that 
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if the Public User Identity is stored as registered in the HSS, and there are S-CSCF restoration information 
related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information 
together with the user profile in the SAA. The result code shall be set to 

DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched registered services for 
the Public User Identity. 

If there are more than one group of S-CSCF restoration information related to the Public User Identity, which may 
happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include all of the S-CSCF 
restoration information in the SAA. One group of S-CSCF restoration information corresponds to one Private User 
Identity. 

If the S-CSCF restoration information received includes the UE"s subscription information, the S-CSCF shall construct 
a NOTIFY message according to the information and send it to the UE (or UEs if the IMPU is shared between several 
IMPIs) to trigger a new registration at anytime after normal processing of the terminating request. 

4.3.3 S-CSCF Restoration after Failure 

If the S-CSCF returned by the HSS during location query procedure fails, the I-CSCF is unable to contact the S-CSCF 
during terminating procedure. In this case, the I-CSCF shall send LIR to the HSS to explicitly request S-CSCF 
capabilities. If the HSS returns the S-CSCF capabilities to the I-CSCF, after re-selection of another S-CSCF according 
to the S-CSCF capabilities, the I-CSCF shall forward the service request to the new S-CSCF. The HSS and this new S- 
CSCF shall behave as described in clause 4.3.2, except that the HSS shall overwrite the S-CSCF name when receiving 
the SAR request, only if there is a previous explicit LIR request for S-CSCF capabilities. 

4.4 UE Originating Procedure 

4.4.1 Introduction 

The following clauses specify the behaviour of HSS, S-CSCF and P-CSCF if they support the IMS Restoration feature. 

4.4.2 S-CSCF Restoration after Restart 

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to 
the fact that it may have lost profile updates from the HSS in the service interruption period. If such a S-CSCF receives 
an originating request different from SIP REGISTER coming from the UE, the S-CSCF shall send SAR to the HSS with 
Server Assignment Type set to NO_ASSIGNMENT to restore the user data. If the S-CSCF name sent in the Server- 
Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different, which may 
happen if S-CSCF reassignment occurred during a terminating restoration before, the HSS shall not overwrite the S- 
CSCF name; instead it shall send a response to the S-CSCF with result code set to 

DIAMETER_UNABLE_TO_COMPLY, as specified in the 3GPP TS 29.228 [3]. If there are S-CSCF restoration 
information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration 
information together with the user profile in the SAA to the S-CSCF. If the HSS returns an error 
DIAMETER_UNABLE_TO_COMPLY to the S-CSCF, the S-CSCF shall then return a specific error response to the 
UE to trigger a new registration. 

If there are more than one group of S-CSCF restoration information related to the Public User Identity stored in the 
HSS, which may happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include 
all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information corresponds to one 
Private User Identity. 

If the S-CSCF receives SAA with the service profile of the user, the S-CSCF shall continue the originating service as 
normal. 

If the S-CSCF receives SAA with S-CSCF restoration information and the S-CSCF restoration information includes the 
UE"s subscription information, the S-CSCF shall construct a NOTIFY message according to the information and send it 
to the UE (or UEs if the IMPU is shared between several IMPIs) to trigger a new registration at anytime after normal 
processing of the originating request. 
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4.4.3 S-CSCF Restoration after Failure 

If the UE initiates an originating service request different from SIP REGISTER and the P-CSCF is unable to contact the 
S-CSCF in the Route, the P-CSCF shall return a specific error response to the UE to trigger a new registration. 

4.5 SIP-AS Originating Procedure 

4.5.1 Introduction 

The following clauses specify the behaviour of HSS, I-CSCF and S-CSCF if they support the IMS Restoration feature. 

4.5.2 S-CSCF Restoration after Restart 

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to 
the fact that it may have lost profile updates from the HSS in the service interruption period. If such S-CSCF receives 
an originating request on behalf of a user (i.e. top-most route header in request contains "orig" parameter) coming from 
an AS, the S-CSCF shall send SAR to the HSS with Server Assignment Type set to UNREGISTERED_USER to 
inform the HSS that the user is unregistered. HSS and S-CSCF proceed as indicated in 3GPP TS 29.228 [3], except that: 

if the Public User Identity is stored as registered in the HSS, and there is S-CSCF restoration information 
related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information 
together with the user profile in the SAA. The result code shall be set to 

DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched originating services for 
the Public User Identity. if the Public User Identity is stored as registered in the HSS, and there is no S-CSCF 
restoration information related to the Public User Identity stored in the HSS, the HSS shall send the user 
profile in the SAA and set the registration state for the Public Identity to unregistered. The result code shall be 
set to DIAMETER_SUCCESS. The S-CSCF shall trigger matched originating unregistered services for the 
Public User Identity. 

if the S-CSCF name sent in the Server- Assignment-Request command and the previously assigned S-CSCF 
name stored in the HSS are different, the HSS shall not overwrite the S-CSCF name. Result Code will be 
DIAMETER_IDENTITY_ALREADY_REGISTERED. The S-CSCF shall return a specific error response to 
AS. The AS shall resend the request to the I-CSCF. 

NOTE: The address of the S-CSCF can be obtained by AS either by querying the HSS on the Sh interface or 
during third-party registration. It may happen that if AS is using third party registration and a 
reassignment occurred during a terminating request, AS will have the wrong S-CSCF name. 

4.5.3 S-CSCF Restoration after Failure 

If the application server sends the originating service request on behalf of the user to the S-CSCF, and the S-CSCF can 
not be contacted, after timeout, the application server shall resend the originating service request to the I-CSCF. 

If the application server sends the originating service request directly to the I-CSCF, or resends the originating service 
request to the I-CSCF due to the S-CSCF can not be contacted, the I-CSCF shall behave as in section 4.3.3. The S- 
CSCF and HSS shall behave as in section 4.5.2, except that the HSS shall overwrite the S-CSCF name when receiving 
the SAR request, only if there is a previous explicit LIR request for S-CSCF capabilities. 

4.6 S-CSCF Data Restoration Information Backup and Update 
Procedures 

4.6.1 Introduction 

The following clauses specify the behaviour of HSS and S-CSCF if they support the IMS Restoration feature. 
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4.6.2 Backup and Update of S-CSCF Restoration Information during 
Registration Process 

The S-CSCF shall backup the following data in the HSS during the initial registration process. 

the list of SIP proxies in the path (normally it would be just the P-CSCF address) 
the Contact Information (Contact Addresses and Contact Header parameters) 
the Authentication Information (SIP- Authentication-Scheme) 

This is done with an additional information element in the SAR requesting user information, in addition to the basic set 
of information required to handle traffic, as specified in the 3GPP TS 29.228 [3]. The information is associated with the 
Private User Identity and the Implicit Registration Set that is affected by the SAR request. The HSS shall store this 
information. 

If any of the above data is changed, the S-CSCF shall update it in the HSS using SAR request with Server- Assignment- 
Type set to RE_REGISTRATION and the User Data Already Available parameter set to 
USER_DATA_ALREADY_AVAILABLE, as specified in the 3GPP TS 29.228 [3]. 

4.6.3 Backup and Update of S-CSCF Restoration Information after UE"s 
Subscription 

If the S-CSCF receives the UE"s subscription to notification of the reg-event for the first time, the S-CSCF shall send 
an SAR to the HSS to store the following UE"s subscription information. 

Call-ID, From, To, Record-Route, Contact 

To avoid frequent storing of the subscription information in the HSS, the CSeq should not be included in the S-CSCF 
restoration information. Instead, the CSCF shall ensure that subsequent notification after retrieving this data includes a 
sufficiently large Cseq value so that the UE is able to accept it. 

This is done with Server Assignment Type set to RE_REGISTRATION and the User Data Already Available parameter 
set to USER_DATA_ALREADY_AVAILABLE in the SAR, as specified in the 3GPP TS 29.228 [3]. The information 
is associated with the Private User Identity affected by the SAR request. The HSS shall store this information. 

If any of the above data is changed, the S-CSCF shall update it in the HSS using SAR request with Server- Assignment- 
Type set to RE_REGISTRATION and the User Data Already Available parameter set to 
USER_DATA_ALREADY_AVAILABLE, as specified in the 3GPP TS 29.228 [3]. 

The S-CSCF shall send the registration data together with the subscription data as one S-CSCF restoration information. 
Each time the HSS receives the S-CSCF restoration information related to the same Private User Identity in the SAR 
with Server- Assignment-Type set to RE_REGISTRATION, the HSS shall overwrite the previous S-CSCF restoration 
information. 



Recovery after P-CSCF failure 



5.0 General 

The following clauses show the requirements and information flows of IMS Restoration Procedures for the P-CSCF 
service interruption in each of the scenarios where they apply. 

Procedures over S9 between V-PCRF and H-PCRF are not supported in this release of the specification. 

5.1 Update PDP context/Bearer at P-CSCF failure 

These flows show the procedures performed by the network at P-CSCF failure after user initiated registration.. 
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5.1.1 General requirements 

The following points are considered as requirements for the purpose of these procedures. 

1 . P-CSCF discovery is performed by requesting and provisioning P-CSCF address(es) within Protocol 
Configuration Options (PCO), as specified in 3GPP TS 29.061 [9], subclause 13a.2.1 

2. The UE supports PCO IE, as specified in 3GPP TS 24.008 [4], subclause 10.5.6.3. 

3. For the GTP based S5 interface, GTPvl, as specified in 3GPP TS 29.060 [8] or GTPv2, as specified in 3GPP 
TS 29.274 [10] are supported by the GGSN/PDN-GW. 

4. For the PMIP based S5 interface, PMIPv6, as specified in 3GPP TS 29.275 [15] is supported by the PDN-GW. 

5.1 .2 Network recovery information flow - Update PDP context / Bearer 



UE 



GGSN/PDN-GW 



1 . GreatePDPGontextRequest / 
CreateSessionRequest 



2. CreatePDPGontextResponj 
CreateSessionResponse (list of P-CSGI- 



5. SIP REGISTER 



e/ 
addresses) 



Start monitoring of 
P-CSCF 



10. 200O< 



P-CSCF 



PCRF 



3. Diameter CCR 



4. DianeterCCA 



6. Rx Push (P-CSCF address) 



7. Rx Push Rsp 



8. Gx Pust (P-CSCF address) 



5x Push Rsp 



1 1 . UpdatePDPContextRequest / UpdateBearerjRequest 
list of P-CSCF addresses) 




12. UpdatePDPContextResponse / 
UpdateBearerResponse 

► 



13. S 



P REGISTER 



Figure 5.1.2a: P-CSCF failure (new list of P-CSCFs in PCO) 
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1 . The UE initiates an IP-CAN session. 

2. P-CSCF discovery is performed. A list of P-CSCF addresses is received in CreatePDPContextResponse / 
CreateBearerResponse within the PCO IE. 

3. The GGSN/PDN-GW sends CCR to request for PCC rules, as specified in 3GPP TS 29.212 [6]. 

4. The PCRF provides PCC rules to be applied in CCA. 

5. The UE performs an initial registration towards a P-CSCF from the received list. 

6. The P-CSCF sends Rx Push (see 3GPP TS 29.214 [7]) to provide the PCRF with the P-CSCF selected by the 
UE. 

7. The PCRF sends Rx Push reponse. 

8. The PCRF uses a Gx push procedure to provide the GGSN/PDN-GW with the P-CSCF address. 

9. The GGSN/PDN-GW stores this address for the UE and sends Gx Push Rsp. Also, the GGSN/PDN-GW starts 
monitoring the health of the P-CSCF if not already done. 

10. The P-CSCF sends 200 OK to the UE. 

11. A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW. The GGSN/PDN-GW sends a new PCO IE 
with a new list of P-CSCF addresses (which does not include the failed P-CSCF) to all UEs associated to the 
failed P-CSCF address. 

12. The UEs acknowledge the request. 

13. Upon receiving the new list of P-CSCFs, if the P-CSCF in use is missing, each UE performs an initial 
registration towards a new P-CSCF. 



5.1 .3 Network recovery information flow witin S5 PMIP 



UE 



S-GW 



PDN-GW 



l.PBU(PCO) 



2. PBA (list of P-CSCF address in P( :0) 



P-CSCF 



PCRF 



Same as Step 3-10 Figure 5.1.2a: P-CSCF failure 



11. UPN (New list of P-CSCF 



12. UPA 



13. If the PGW knows the SOW does not support the PMIP Update 
Notification procedure, the PGW shall release the PMIP binding with 
cause code "Reactivation Requested". 




14. Upon receiving the new list of P-CSCFs, each UE performs an initial registration towards a new P-CSCF. 



Figure 5.1.3: P-CSCF failure with S5 PMIP 
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1 ~ 10. The IMS session is setup as described in subclause 5.1.2 except S5 PMIP procedure is used between SGW 
and PGW. 

1 1. Once a P-CSCF failure is detected via Gi/sGi by the PDN-GW, the PDN-GW shall send a PMIP UPN message 
(MN ID, IPv6 prefix, IPv4 HoA, APN, PDN connection, PCO, Notification Indicator, and Additional 
parameters) as specified in IETF draft-krishnan-netext-update-notifications-00 [16]. The PCO contains a new list 
of P-CSCF address. The Notification Indicator indicates that there is a P-CSCF failure. 

12. If the SGW supports the PMIP Update Notification message, it shall send Update Bearer Request message with 
the new list of P-CSCF address in the PCO to the MME/SGSN as part of the PGW initiated bearer modification 
procedure as specified in 3GPP TS 23.401 [17]. 

Once the Update Bearer Response message is received, the SGW shall response with a PMIP UPA message 
(MN ID, IPv6 prefix, IPv4 HoA, APN, PDN connection, PCO, and Additional parameters) as specified in IETF 
draft-krishnan-netext-update-notifications-00 [16]. 

13. If the PGW knows the SGW does not support the PMIP Update Notification procedure, the PGW shall skip step 
1 1 and release the PMIP binding with cause code "Reactivation Requested". 

14. Upon receiving the new list of P-CSCFs, the UE may perform an initial registration towards a new P-CSCF. 

5.2 Inform UE about P-CSCF failure 

These flows show the procedures performed by the network at P-CSCF failure after user initiated registration.. 

5.2.1 General requirements 

The following points are considered as requirements for the purpose of these procedures. 

1 . P-CSCF discovery is performed by requesting P-CSCF address(es) via DHCP method, as specified in 3GPP TS 
29.061 [9], subclause 13a.2.1 

2. The UE supports PCO IE, as specified in 3GPP TS 24.008 [4], subclause 10.5.6.3. 

3. For the GTP based S5 interface, GTPvl, as specified in 3GPP TS 29.060 [8] or GTPv2, as specified in 3GPP 
TS 29.274 [10] are supported by the GGSN/PDN-GW 

4. For the PMIPv6 based S5 interface, PMIPv6, as specified in 3GPP TS 29.275 [15] is supported by the PDN- 
GW. 

5.2.2 Network recovery information flow - Inform UE at P-CSCF failure 
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UE 



GGSN/PDN-GW 



1. GreatePDPContextReque^t/ 
CreateSessionRequest 



2. CreatePDPContextRespons|e/ 
GreateSessionResponse 

■< 




3. DHCP request /Responi 



e (P-CSCF address) 



DHGP server 




6. SIP REGISTER 



3. Gx Push (P-CSCF addre;s) 




12. P-CSCF failure indicafon 

■< 

13. P-CSCF failure indication ack 




14. DHCP request / Respon 



;e (P-CSCF address) 




15. SIP REGISTER 



P-CSCF 



PCRF 



4. Diameter CCR 



5. Diameter CCA 



7. Rx Push (P-CSCF addre;s) 



10. GxPush Rsp 



8. Rx Push Rsp 



Figure 5.2.2a: P-CSCF failure for DHCP based scenarios 

1-2. The UE initiates an IP-CAN session. 

3. P-CSCF discovery is performed using DHCP based method. The GGSN/PDN-GW relays/send the list of P- 
CSCF addresses in DHCP response. 

NOTE: The DHCP response can include either a list of P-CSCF lPv4/lPv6 addresses or a list of FQDNs (see 

IETF RFC 3361 [11] and IETF RFC 3319 [13]). If P-CSCF FQDNs were provided, the UE uses DNS SIP 
server resolution mechanism (see IETF RFC 3263 [12]) 

4. The GGSN/PDN-GW sends CCR to request for PCC rules, as specified in 3GPP TS 29.212 [6]. 
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5. The PCRF provides PCC rules to be applied in CCA. 

6. The UE performs an initial registration towards the P-CSCF received. 

7. The P-CSCF sends Rx Push (see 3GPP TS 29.214 [7]) to provide the PCRF with the P-CSCF selected by the 

UE, 

8. The PCRF sends Rx I'ush reponse. 

9. The PCRF uses a Gx push procedure to provide the GGSN/PDN-GW with the P-CSCF address. 

10. The GGSN/PDN-GW stores this address for the UE and sends Gx Push Rsp. Also, the GGSN/PDN-GW starts 
monitoring the health of the P-CSCF if not already done. 

11. The P-CSCF sends 200 OK to the UE. 

12. A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW. The GGSN/PDN-GW informs to all UEs 
associated to the failed P-CSCF address that the P-CSCF is not available. 

13. The UEs acknowledge the request. 

14. The UE requests P-CSCF addresses (if needed) via new DHCP request. 

15. The UE selects a new P-CSCF and initiates an initial IMS registration. 

5.2.3 Network recovery information flow - Inform UE at P-CSCF failure 
with S5 PMIP 



UE 



S-GW 



PDN-GW 



T 



P-CSCF 



PCRF 



Same as Step 1-11 Figure 5.2.2a: P-CSCF failure for DHCP based scenarios 



12.1. UPN (P-CSCF failure 



12.2 UPA 



12.3 If the PGW knows the SOW does not support the PMIP Update 
Notification procedure, the PGW shall skip step 12.1 and may release the PMIP 
binding with cause code "Reactivation Requested". 



r 




Same as Step 13 ~ 15 Figure 5.2.2a: P-CSCF failure for DHCP based scenarios 



Figure 5.2.3-1 : P-CSCF failure for DHCP based scenarios with S5 PMIP 

1 ~ 11. Same as figure 5.2.2a step 1-11 

12. A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW. The GGSN/PDN-GW informs to all UEs 
associated to the failed P-CSCF address that the P-CSCF is not available. 

- The PDN-GW shall send a PMIP UPN message (MN ID, IPv6 prefix, IPv4 HoA, APN, PDN connection, 
PCO, Notification Indicator, and Additional parameters) as specified in IETF draft-krishnan-netext-update- 
notifications-00 [16]. The PCO contains a P-CSCF failure Indicator. The Notification Indicator indicates that 
there is a P-CSCF failure. 
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If the SGW supports the PMIP Update Notification message, it shall send Update Bearer Request message 
with the P-CSCF failure Indicator in the PCO to the MME as part of the PGW initiated bearer modification 
procedure as specified in 3GPP TS 23.401 [17]. Once the Update Bearer Response message is received, the 
SGW shall response with a PMIP UPA message (MN ID, IPv6 prefix, IPv4 HoA, APN, PDN connection, 
PCO, and Additional parameters) as specified in IETF draft-krishnan-netext-update-notifications-00 [16]. 

If the PGW knows the SGW does not support the PMIP Update Notification procedure, the PGW may 
release the PMIP binding with cause code "Reactivation Requested". 

13 ~ 15. Same as figure 5.2.2a step 13 -15. 

5.3 Network recovery information flow - UE uses keep alive mechanism 




Figure 5.3a: P-CSCF failure detected by UE 

1. After establishment of an IP -CAN session and acquiring P-CSCF addresses, the UE performs initial registration 
towards a P-CSCF. 

2. If registration is successful, the UE monitors the P-CSCF health according to draft-ietf-sipcore-keep-01 [14] 

3. When a failure is detected, the UE acquires new P-CSCF addresses (if needed) and performs an initial 
registration. 
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